home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000105_icon-group-sender _Wed Apr 9 09:14:10 1997.msg < prev    next >
Text File  |  2000-09-20  |  1KB  |  32 lines
  1. Message-Id: <199704091947.AA11216@cheltenham.cs.arizona.edu>
  2. Received: by cheltenham.cs.arizona.edu; Wed, 9 Apr 1997 12:47:37 MST
  3. Date: Wed, 9 Apr 97 17:09:32 BST
  4. From: Jeff Dalton <jeff@aiai.ed.ac.uk>
  5. Subject: Re: Problem with Icon 9.3
  6. To: eka@corp.cirrus.com (Eka Laiman), ko@surya.ho.att.com (Kostas Oikonomou)
  7. Cc: icon-group@cs.arizona.edu
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9. Status: RO
  10. Content-Length: 895
  11.  
  12. > Wow, indexing using "list"s?
  13. > 
  14. > I do not know if ICON's tables are built with this kind of operation in
  15. > mind. I personally think that ICON tables are like "hash table" where the
  16. > indexing can be done using both "strings" or "integers". According to the
  17. > definition: "Tables resemble lists, except that the keys, or 'subscripts',
  18. > need not be integers but can be *values of any type*." I have not tried to
  19. > do indexing based on "float" yet, although theoretically that's possible
  20. > :-)
  21.  
  22. But doesn't "list" fall under "any type".
  23.  
  24. Hash tables in Common Lisp can be indexed by lists.  (How it
  25. depends on the "test" specified when the table is created.  For
  26. a table where the test is "equal", the contents of the list matter.
  27. For one there the test is "eql" (which is pretty close to identity),
  28. only the "address" of the lisyt would be used.  A similar rule applies
  29. to strings.)
  30.  
  31. -- jeff
  32.